In the field of transaction processing, units of work are generally required to have what are known as the ACID properties. ACID is an acronym representing the four unit of work properties of: Atomicity, Consistency, Isolation and Durability. Atomicity requires that either all the operations of the unit of work must be seen to occur or none must be seen to occur. Consistency requires a unit of work to maintain the consistency of in the data on which it operates. Isolation requires a unit of work not to read the intermediate results of another transaction. Durability requires the results of a committed unit of work to be made permanent and that the other ACID attributes can be guaranteed even in the event of system failure. However the responsibility to ensure these properties falls to different components. For example, if the unit of work is a transaction, atomicity is provided by the transaction co-ordinator, consistency by the application, isolation and durability by a resource manager. Further in some units-of-work not all such properties are observed, for example, isolation is not observed for a unit of work which is a long running (extended) transaction and which comprises several transactions.
For example, a well known and understood unit of work is a transaction and it is the role of a transaction co-ordinator or middleware to provide atomicity. Thus, for example, if an application involves two operations in a transaction and then requests the transaction co-ordinator to commit the transaction, the transaction co-ordinator must ensure that both operations commit (succeed). Alternatively if the application requests the transaction co-ordinator to back out the transaction, the transaction co-ordinator must ensure that both operations are backed out (fail).
A major problem in providing atomicity is that it must be guaranteed even in the event of a failure of the system on which the transaction co-ordinator is executing. For example, if a transaction involves two operations and then commits, the system might fail after the transaction co-ordinator has committed the first operation but before the same has been done for the second operation. As a result when the system is restarted the transaction co-ordinator must ensure that the second operation also commits. In order to provide this functionality it is necessary for the transaction co-ordinator to maintain a non-volatile log which survives a system failure and which records the progress of each transaction. For example the transaction co-ordinator will maintain in the log a sequential record of the operations involved in each transaction and the progressive states of the transaction. Further, at certain points in the transaction the transaction must be held whilst the transaction co-ordinator ensures that a log record has been written to non-volatile storage. However, writing to a log is time consuming.